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This application is related to similar subject matter as co- 
pending and commonly assigned U.S. Patent Application Serial Nos. 

(Attorney Docket No. RSW9-2000-0101) entitled 

"APPARATUS AND METHOD FOR E-BUSINESS SERVICE BROKERAGE", filed 



"APPARATUS AND METHOD FOR VERIFYING CATEGORIZATION OF SERVICES 
USING CANONICAL SERVICE DESCRIPTION TESTS", filed on even date 



entitled "SERVICE TAXONOMY CRAWLER APPARATUS AND METHOD", filed 
on even date herewith, each of which are hereby incorporated by 
reference . 



1. Technical Field: 

The present invention is directed to an apparatus and method 
for categorizing services using canonical service descriptions. 
More specifically, the present invention is directed to an 
apparatus and method for electronic business (e-business) service 
categorization for use with an electronic service broker in order 
to place e-business services into categories within taxonomies 
that are searchable at run time. 

2. Description of Related Art: 

A world in which a myriad of e-business services connect and 
collaborate with one another over the Internet is fast becoming a 
reality. Business-to-business (B2B) service interactions already 
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exist using a variety of schemes that range from very rigid 
point-to-point Electronic Data Interchange (EDI) interactions to 
open Web auctions, e.g., Ariba, Chemdex, eSteel, and eBay. 
Thousands of businesses have already made some of their IT 
services available to their customers or partners on the Web. 
Most of these services are intended for use from a browser. But 
with technology such as WIDL from webMethods 

(www.webmethods.com), many of the Web-enabled services can also 
participate in B2B collaborations. 

Known e-business services collaborate without any 
overarching vision or architecture. Techniques for B2B 
collaboration vary from one case to another. As the number and 
type of e-business services grows, the ability of an e-business 
consumer to locate and contact a provider of an e-business 
service will become increasingly difficult. Today, there is no 
vendor neutral archtectural mechanism for classifying e-business 
services such that an e-business service consumer can locate and 
contact a provider of a desired e-business service. Thus, it 
would be beneficial to have an apparatus and method for 
classifying services in such a manner as to make them searchable 
and usable at run-time. 
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SUMMARY OF THE INVENTION 



The present invention provides an apparatus and method for 
service classification. The present invention makes use of 
canonical service descriptions which designate minimum 
requirements for a service to be classified into a corresponding 
classification. Based on the canonical service description, it 
can be determined whether a service that wishes to be classified 
into a particular classification of a taxonomy on a service 
broker meets the minimum requirements, in terms of functionality 
and application program interface (API) , for example, for that 
classification. Furthermore, the use of canonical service 
descriptions ensures that all services classified into a 
particular classification have a minimum level of functionality 
that will allow them to function properly when invoked. 



RSW9-2000-0102-US1 



4 



BRIEF DESCRIPTION OF THE DRAWINGS 

The novel features believed characteristic of the invention 
are set forth in the appended claims. The invention itself, 
however, as well as a preferred mode of use, further objectives 
and advantages thereof, will best be understood by reference to 
the following detailed description of an illustrative embodiment 
when read in conjunction with the accompanying drawings, wherein: 

Figure 1 is a diagram illustrating a distributed data 
processing system according to the present invention; 

Figure 2 is an exemplary block diagram of a server according 
to the present invention; 

Figure 3 is an exemplary block diagram of a client according 
to the present invention; 

Figure 4 is an exemplary block diagram illustrating the 
interaction of e-business service consumers with e-business 
service providers via a broker; 

Figure 5 is an exemplary diagram illustrating a canonical 
service description in accordance with the present inventions- 
Figure 6 is an exemplary diagram illustrating the 
registration of a service in multiple taxonomies of various 
service brokers; 

Figure 7 is an exemplary diagram illustrating the 
hierarchical levels traversed in a service broker to identify an 
e-business service provider in accordance with the present 
invention; 

Figure 8 is a flowchart outlining an exemplary operation of 
the present invention when registering a new service with a 
broker; and 



RSW9-2000-0102-US1 5 

Figure 9 is a flowchart outlining an exemplary operation 
the present invention when identifying an e-business service 
provider based on the categorization of the present invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 



With reference now to the figures, and in particular with 
reference to Figure 1, a pictorial representation of a 
5 distributed data processing system is depicted in which the 
present invention may be implemented. Distributed data 
processing system 100 is a network of computers in which the 
present invention may be implemented. Distributed data 
^ processing system 100 contains network 102, which is the medium 
10 ; y used to provide communications links between various devices and 
:n computers connected within distributed data processing system 

100. Network 102 may include permanent connections, such as wire 
or fiber optic cables, or temporary connections made through 
"* s telephone connections. 
15 £t In the depicted example, server 104 is connected to network 

U 102, along with storage unit 106. In addition, clients 108, 110 

and 112 are also connected to network 102. These clients, 108, 
l~ L HO and 112, may be any type of computing device capable of 

sending and/or receiving information via the network 102. For 
20 example, the clients may be personal computers, network 

computers, personal digital assistants, Internet capable cellular 
telephones, and the like. For purposes of this application, a 
network computer is any computer coupled to a network which 
receives a program or other application from another computer 
25 coupled to the network. In the depicted example, server 104 

provides data, such as boot files, operating system images and 
applications, to clients 108-112. Clients 108, 110 and 112 are 
clients to server 104. Distributed data processing system 100 
may include additional servers, clients, and other devices not 
30 shown. 

In the depicted example, distributed data processing system 
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100 is the Internet, with network 102 representing a worldwide 
collection of networks and gateways that use the TCP/IP suite of 
protocols to communicate with one another. At the heart of the 
Internet is a backbone of high-speed data communication lines 
between major nodes or host computers consisting of thousands of 
commercial, government, education, and other computer systems 
that route data and messages. Of course, distributed data 
processing system 100 also may be implemented as a number of 
different types of networks such as, for example, an intranet or 
a local area network. Figure 1 is intended as an example and not 
as an architectural limitation for the processes of the present 
invention. 

Referring to Figure 2, a block diagram of a data processing 
system which may be implemented as a server, such as server 104 
in Figure 1, is depicted in accordance with the present 
invention. Data processing system 200 may be a symmetric 
multiprocessor (SMP) system including a plurality of processors 
202 and 204 connected to system bus 206. Alternatively, a single 
processor system may be employed. Also connected to system bus 
206 is memory controller/cache 208, which provides an interface 
to local memory 209. I/O bus bridge 210 is connected to system 
bus 206 and provides an interface to I/O bus 212. Memory 
controller/cache 208 and I/O bus bridge 210 may be integrated as 
depicted. Peripheral component interconnect (PCI) bus bridge 214 
connected to I/O bus 212 provides an interface to PCI local bus 
216. A number of modems 218-220 may be connected to PCI bus 216. 
Typical PCI bus implementations will support four PCI expansion 
slots or add-in connectors. Communications links to network 
computers 108-112 in Figure 1 may be provided through modem 218 
and network adapter 220 connected to PCI local bus 216 through 
add-in boards. Additional PCI bus bridges 222 and 224 provide 
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interfaces for additional PCI buses 226 and 228, from which 
additional modems or network adapters may be supported. In this 
manner, server 200 allows connections to multiple network 
computers. A memory mapped graphics adapter 230 and hard disk 
232 may also be connected to I/O bus 212 as depicted, either 
directly or indirectly. 

Those of ordinary skill in the art will appreciate that the 
hardware depicted in Figure 2 may vary. For example, other 
peripheral devices, such as optical disk drives and the like, 
also may be used in addition to or in place of the hardware 
depicted. The depicted example is not meant to imply 
architectural limitations with respect to the present invention. 
The data processing system depicted in Figure 2 may be, for 
example, an IBM RISC/System 6000, a product of International 
Business Machines Corporation in Armonk, New York, running the 
Advanced Interactive Executive (AIX) operating system. 

With reference now to Figure 3, a block diagram of a data 
processing system in which the present invention may be 
implemented is illustrated. Data processing system 300 is an 
example of a client computer. Data processing system 300 employs 
a peripheral component interconnect (PCI) local bus architecture. 
Although the depicted example employs a PCI bus, other bus 
architectures, such as Micro Channel and ISA, may be used. 

Processor 3 02 and main memory 304 are connected to PCI local 
bus 306 through PCI bridge 308. PCI bridge 308 may also include 
an integrated memory controller and cache memory for processor 
302. Additional connections to PCI local bus 306 may be made 
through direct component interconnection or through add- in 
boards. In the depicted example, local area network (LAN) 
adapter 310 , SCSI host bus adapter 312, and expansion bus 
interface 314 are connected to PCI local bus 306 by direct 
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component connection . 

In contrast, audio adapter 316 , graphics adapter 318, and 
audio/video adapter (A/V) 319 are connected to PCI local bus 306 
by add- in boards inserted into expansion slots. Expansion bus 
interface 314 provides a connection for a keyboard and mouse 
adapter 32 0, modem 322, and additional memory 324. 

In the depicted example, SCSI host bus adapter 312 provides 
a connection for hard disk drive 326, tape drive 328, CD-ROM 
drive 33 0, and digital video disc read only memory drive (DVD- 
ROM) 332. Typical PCI local bus implementations will support 
three or four PCI expansion slots or add- in connectors. 

An operating system runs on processor 302 and is used to 
coordinate and provide control of various components within data 
processing system 300 in Figure 3. The operating system may be 
commercially available operating system, such as Linux, which is 
available from International Business Machines Corporation. An 
object oriented programming system, such as Java (a trademark of 
Sun Corporation) , may run in conjunction with the operating 
system, providing calls to the operating system from Java 
programs or applications executing on data processing system 300 
Instructions for the operating system, the object-oriented 
operating system, and applications or programs are located on a 
storage device, such as hard disk drive 326, and may be loaded 
into main memory 304 for execution by processor 302. 

Those of ordinary skill in the art will appreciate that the 
hardware in Figure 3 may vary depending on the implementation. 
For example, other peripheral devices, such as optical disk 
drives and the like, may be used in addition to or in place of 
the hardware depicted in Figure 3 . The depicted example is not 
meant to imply architectural limitations with respect to the 
present invention. For example, the processes of the present 
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invention may be applied to multiprocessor data processing 
systems . 

The present invention provides an apparatus and method for 
categorizing services, e.g., e-business services, such that the 
categories of services may be searched to identify a supplier of 
a desired service. Based on the categorization of services, 
brokers may be established for providing a brokerage service to 
identify service providers. 

With the present invention, a service provider may register 
with one or more brokers to thereby publicize the availability of 
their services. When a service consumer wishes to make use of a 
service, the consumer contacts a broker, provides the criteria of 
the service desired, and instructs the broker to find a 
compatible provider of the desired service. The broker may then 
provide the service consumer with information indicating how to 
contact the service provider; 

Figure 4 is an exemplary block diagram illustrating the 
interaction of service consumers with service providers via a 
broker in accordance with the present invention. With the 
present invention, service consumer 410 is a requester of 
services, server providers 430-450 are suppliers of services, and 
broker 420 facilitates service consumers identifying compatible 
service providers. 

The service consumer 410 may be any type of device that 
makes use of services available via the network 102. For 
example, the service consumer 410 may be a client device, such as 
client devices 108-112 in Figure 1. 

The description of the present invention refers to 
"services" which are requested by service consumers and supplied 
by service providers. The term "services" means any service that 
satisfies a business agenda of the service consumer. The 
"service" may collaborate with applications and services of other 
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consumers, providers, and organizations. A service may be, for 
example, credit card authorization, credit report ranking, 
printing a document, applying postage to the document, and any 
other service that may be provided or contracted for via a 
network . 

The service consumer 410 sends requests for services to the 
broker 420 via the network 102 . The request is properly 
formatted so that the broker 42 0 may determine the category of 
service which is being requested by the service consumer 410. 
Based on the request and request parameters, the broker 42 0 
identifies one or more service providers that satisfy the 
request, if any compatible service providers are registered with 
the broker 420, in a manner described hereafter. The service 
consumer may then select a service provider from those identified 
and obtain, from the broker 42 0, information identifying the 
manner by which the service consumer may contact and obtain the 
requested service from the service provider. 

The service providers 430-450 may be implemented as any 
device coupled to the network 102 that is capable of providing or 
contracting for a service based on requests received over the 
network 102. The broker 42 0 is any type of device that is 
capable of receiving service requests from a service consumer 
410, identify a service provider that provides the requested 
service, and provides contact information to the service consumer 
via the network 102. The service providers 430-450 and the 
broker 420 may be implemented, for example, in a server 
apparatus, such as server 104. 

In order to maximize the benefit of services offered via a 
large and varying network environment, such as the Internet, a 
unified organizing principle must be adopted by which service 
consumers may be made aware of services that are available and 
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the providers of these services. The present invention provides 
an architecture by which services may be categorized in such a 
manner as to facilitate informing consumers of the availability 
of services and their providers. 

Categorization according to the present invention makes use 
of one or more taxonomies created and supported by each broker. 
The taxonomies are hierarchical in nature to reflect commonalties 
larger than the individual species. Just as with biological 
taxonomies, there is more than one way to categorize species of 
services and hence, there may be more than one possible taxonomy 
into which a service is classifiable. Because there may be many 
different possible taxonomies into which a service may be 
classified, a service provider may need to register its services 
with multiple brokers, each broker supporting a different 
taxonomy into which the service may be classified. 

The service provider decides, at registration time, in which 
category, or categories, the service is to be registered. For 
example, if the service is air conditioning repair, the service 
provider may decide to register the service in a category of a 
taxonomy identified by home>repair>airconditioning or 
household>equipment>airconditioning>repair, or the like. 

Each category of a taxonomy must define the semantics, i.e. 
what the services in the category do, as well as the application 
program interface (API) used to communicate with the service 
providers, i.e. how to invoke the services. In order to provide 
such classifications, a canonical service description (CSD) may 
be used to describe each classification. The CSD provides a 
mechanism by which a service may be classified that is 
recognizable by all parties to the service brokerage transaction. 
That is, the CSD based classification is recognized by the 
service consumer, the broker, and the service providers. 

All services in a category must implement the canonical 
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service description for that category, although they may do more 
than is provided in the CSD, i.e. the CSD provides the minimum 
requirements for a service to be classified into a corresponding 
category. 

The use of CSDs that define the minimum requirements for 
services in a category provides a mechanism that facilitates 
searching of taxonomies at runtime. At runtime there is little, 
if any, interaction with a human user. Thus, in order to perform 
searching of categories in a taxonomy to identify services, a 
mechanism is needed by which to perform the search. This 
mechanism is the CSD. 

With the present invention, an automatic search of the 
categories in a taxonomy is possible by searching for a matching 
CSD, i.e. a CSD that matches a requested CSD or provides minimum 
requirements corresponding to requirements of a search query. 
Such a search does not require input from a human user at runtime 
because each service categorized into a particular category is 
guaranteed to implement at least the functionality and APIs 
designated by the CSD of that category. 

Figure 5 illustrates an exemplary canonical service 
description. The canonical service description shown in Figure 5 
is provided in the extensible markup language (XML) and 
represents an example canonical service description for a stock 
quote service. The mechanism used for describing the canonical 
service description is the web services description language 
(WSDL) , with CSD related extensions. The use of WSDL is 
standard, defining the "reusable" portion of a web service over 
the Simple Object Access Protocol (SOAP) . 

There are two main elements in the file that distinguish 
this file as a CSD description from other uses of WSDL to define 
"reusable" portions of a service description. These two elements 
are both defined within the CSD namespace extension to the WSDL 
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language. CSD-related elements are inserted into a WSDL using 
the standard extension mechanism defined in the WSDL language. 

The example shown in Figure 5 defines a StockQuoteBinding 
CSD, for use in defining the standard web services interface 
5 definition for stock quoting. Organisations may use this CSD as 
the template for defining U API standard" stock quote web 
services . 

The csd : testService element defines the specific service 
jsdl information of a service that provides validatable results. If a 
10 uj developer wishes to test an implementation of the stock quote web 
5 2 service, as will be discussed in greater detail hereafter, the 
111 developer may invoke the web service implementing the 

StockQuoteBinding and compare the results of this service by 
fU invoking the canonical test service for the CSD identified by the 
15 service definition described in the csd : testService element. 

The csd: categorization element defines the category (s) in 
TV; the taxonomy (s) in which implementations of the CSD should be 
O placed. In this case, web services implementing this CSD are 
eligible to be inserted into the equitylnstruments taxonomy, 
20 defined by the* f inancialWebServicesStandards organization, and 
into the category equityInstruments>equities>quotes> 
nonRealTimeQuotes . 

The CSD shown in Figure 5 is for illustration purposes only 
and is not intended to be limiting in any way. CSDs in 
25 accordance with the present invention may include other 

information in addition to, or in replacement of, the information 
shown in Figure 5 without departing from the spirit and scope of 
the present invention. 

The CSD provides a description of the service that is 
30 provided in such a manner as to be cognizable to the service 

consumer. The CSD includes service descriptions that are both 
human readable and machine parsable. For example, the CSD 
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service descriptions may be implemented in the extensible markup 
language (XML) which is parsable by machines, a word processor 
formatted document, or the like. The CSDs also describe non- 
functional requirements, such as security and authentication 
assumptions, and other prerequisites considered to be common to 
all services in the category. 

The CSD for each category is related to that of the category 
one level up. However, the semantics of a given service may 
differ from the next level up in important ways. That is, a 
specialization of a service at the next level down in the 
hierarchy may implement the same function, but do so in a very 
different way with different argument characteristics and 
different returned results from that of the next level up. Thus, 
the CSD describes how the services in the category differ from 
those in a parent category and any sibling categories in the 
taxonomy. 

The CSDs may provide tests by which membership in the 
category may be determined. These tests may be provided as 
executable tests in XML, or other similar executable languages, 
for example. That is, when a service provider attempts to 
register its service with a broker, the broker may determine 
whether or not the service meets the minimum requirements of a 
chosen category based on the tests included in the corresponding 
CSD. The CSD tests allow a broker to objectively and 
automatically determine that a service satisfies the requirements 
for being included in a particular category. 

The CSD test identifies messages that may be sent to the 
service provider and corresponding reply message that should be 
received from the service provider. These messages may be 
directed to various aspects of the service that is provided by 
the service provider. For example, these messages may be 
directed to security issues, privacy issues, and communication 
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protocols used by the service. 

When a service provider requests to have their service 
registered in a particular category of a taxonomy supported by a 
service broker, the service provider sends a request to the 
service broker identifying the category that the service is 
intending to be registered in as well as the APIs used by the 
service. The API description may include, for example, method 
names, parameter names, parameter types, executable API test 
suites, and the like, such that the service broker can determine 
whether the service implements what it claims to implement before 
registering it in a given category. 

Upon receiving the registration request from the service 
provider, the service broker performs the tests associated with 
the CSD of the selected category. That is, the service broker 
sends the messages included in the tests to the service provider 
and monitors the reply messages received. The sending of the 
messages to the service provider is performed in view of the 
method name, parameter names, parameter types, etc. Included in 
the API description of the registration request. The service 
broker then matches the reply messages received to the "correct" 
reply messages included in the CSD test. If there is a match of 
the test messages, the service is verified as meeting the 
requirements of the CSD and the service is permitted to be 
registered in the selected category. 

If the service implements exactly the API specified in the 
category's canonical service description, the service description 
included with the registration request need not provide any 
further tests. However, any additional functionality beyond the 
API specified in the CSD may be accompanied by additional tests. 
These additional tests are implemented in the same way as the CSD 
tests to confirm that the service provides the functions 
identified. 
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Security constraints on some services may require that the 
taxonomy server be given special certificates or other 
certification information as part of registration so that it can 
execute the tests. In situations that call for extreme security, 
authentication or encryption, the taxonomy server may only 
receive exceptions in response to the tests. Even in that case, 
though, it should receive the correct exceptions, i.e. the 
exception received should indicate that the service is present 
but not responding due to inadequate authentication. 

If a service fails one or more of the tests in the CSD, or 
additional tests included in the registration request, the 
service provider may be provided with a report of which tests 
were satisfied and which tests failed. In this way, the service 
provider is provided with information by which the operator of 
the service provider may modify their service description and 
service functionality to conform to the requirements of the 
selected category. 

Thus, the use of canonical service descriptions provides a 
mechanism by which services may be categorized and verified to 
meet the minimum requirements of the particular categories in 
which they are placed. Thus, if a service is to be registered 
with multiple taxonomies, the service is guaranteed to meet the 
minimum requirements of each category in which it is registered. 

In order for the brokerage mechanism of the present 
invention to operate, service providers must first register with 
one or more brokers in accordance with the taxonomies supported 
by those brokers. In determining with which brokers to register, 
the service provider must balance the service consumer's desire 
to have a "target rich" environment with the need for the service 
provider to be "seen" in the right places. The balance of these 
two concerns results in the need for a service provider to 
examine the taxonomies supported by various brokers and register 



RSW9-2000-0102-US1 18 

the service with those brokers, and in the appropriate 
categories, where service consumers are likely to look for the 
service . 

As an example to illustrate the need to register with 
5 multiple brokers, consider a fictional small retail flower e- 

business in Des Moines, Iowa named "CornFlowers.com," as shown in 
Figure 6. In addition to the general flower retailing business, 
CornFlowers.com specializes in growing and selling a number of 
varieties of orchids. 
10 ,p CornFlowers.com participates as a buyer in at least two B2B 

e-business markets. It buys most of its standard types of 
■ft flowers over a B2B link with its primary wholesaler and it buys 
-•^ specialty items (e.g., accessories, balloons, vases and planters) 
from a florist supplies broker. 
15 CornFlowers.com also wishes to provide flower selling e- 

V* business services to clients via the Internet. CornFlowers.com 

participates as a supplier in two industry-oriented brokers 
2 (FTD.com' s industry broker and SFlowers . com' s industry broker) . 
^" CornFlowers.com also wants to provide flower selling e-business 
20 services to other clients outside of the "big" flower brands 

(FTD, 5 FLOWERS ) . As a result, CornFlowers.com wants to appear in 
flower-related e-marketplaces (e.g., for weddings and funerals) 
in the Des Moines area. CornFlowers.com is also active in 
Orchids of America, a special interest group concerned with the 
25 growing and marketing of orchids. It is in CornFlower . com' s 

business interest to be visible as a provider of B2B services in 
this group as well. 

Note that CornFlower . com' s business success depends upon 
being listed in appropriate, but different, categories in several 
30 taxonomies supported by several different brokers. 

CornFlower.com wishes to be listed geographically in FTD and 
5 FLOWERs . It wishes to be listed by flowers in the Des Moines 
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broker, and wishes to be listed by its specialized orchid 
varieties in the orchid broker. As a result, CornFlower.com 
registers its service in the flowers . FTD . com>Retail>USA>IOWA>Des 
Moines category of the taxonomy supported by the FTD broker, the 
localYellowPages . org>Florists>DownTown category in the taxonomy 
supported by the u AllThingsDesMoines" services yellow pages 
broker, and the OOA. org>Retail>Midwest>Iowa category in the 
Orchids of America broker. 

In registering its service with a broker, the service 
provider submits a registration request to the broker. The 
registration request includes a service description, an API 
designation, and any other non- functional information pertinent 
to the invoking of the service. The API designation and non- 
functional information may be designated in terms of a model 
description. The model description identifies the address by 
which to contact the service provider, the protocols used to 
communicate with the service provider, security used by the 
service provider, authentication and privacy, as well as any 
other non-functional information. 

The registration request further includes an indication of the 
categories within the taxonomies of the broker in which the 
described service may be categorized. 

The determination whether to allow the registration in the 
requested categories may be made based on minimum requirements of 
the category, as designated by the corresponding canonical 
service description, in order to make sure the service to be 
registered is in conformance with other services already 
registered under the categories. These minimum requirements may 
include, for example, security issues, privacy issues, 
communication protocols, and the like, which are designated in a 
CSD. 

The determination of whether or not the service to be 
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registered meets the minimum requirements may be made by a human 
administrator of the service broker or automatically by the 
service broker itself based on canonical service description 
tests, as described above. If a service to be registered is 
identified as meeting the CSD requirements of a particular 
category, the service may be registered under that category. If 
the service to be registered is identified as meeting the CSD 
requirements of more than one category, the service provider may 
be provided with the option to register under one or more of the 
categories . 

If a service to be registered is not identified as meeting 
the requirements of any category in the supported taxonomy, the 
service provider may be provided with the option to request that 
the service broker define a new category in which the service may 
be classified. The administrator of the service broker may then 
decide whether or not to support the new classification and 
inform the service provider of the decision. If the 
administrator agrees to define a new classification, the service 
provider may then register its service with the service broker in 
a manner described above. Otherwise, the service provider will 
be unable to register its service with that particular service 
broker . 

Once a service is registered with a service broker in the 
manner described above, the service is included in the list of 
services associated with the designated category of the service 
broker. By stating that the service is included in the list of 
services what is meant is that the service description and model 
submitted by the service provider is stored in memory in 
association with the categories in which the service was 
registered. 

The service consumer may invoke a requested service by first 
contacting a service broker to identify a provider of the 
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service, obtain the model description for the service provider, 
and then contact the service provider based on the model 
description to thereby obtain the requested service. In 
contacting the service broker, the service consumer sends a 
request for a service to the service broker. The service 
consumer may be associated with the service broker such that the 
request is directed specifically at the service broker, or the 
service request may be broadcast across the network 102 such that 
service brokers having registered service providers meeting the 
requirements of the service request may respond accordingly. 

The service request uses the same service description 
semantics used by the service providers when submitting their 
services to the service brokers for registration. The service 
request is parsable by the service broker to thereby identify the 
categories in the supported taxonomy that may have registered 
services meeting the service request requirements. For example, 
the service request may include an identification of a 
taxonomy/category pair that is requested or may include a CSD 
description of a service requested. 

When the service broker receives the service request, the 
service broker traverses the supported taxonomy to identify one 
or more service providers that may provide the requested service. 
For example, if a taxonomy/ category pair is identified in the 
service request, only those services categorized into the 
identified category are investigated to determine if they match 
the requested service. Alternatively, if only a CSD description 
is provided, the entire taxonomy must be traversed to identify a 
service having the requested CSD. 

Figure 7 is an exemplary diagram illustrating the 
hierarchical levels traversed in a service broker to identify an 
e-business service provider in accordance with the present 
invention. As shown in Figure 7, a service broker 710 hosts a 
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taxonomy registry 720. The taxonomy registry 720 identifies the 
various l...n taxonomies supported by the service broker 710. 
The root node 730 represents the root of the 0...n categories 740 
within the taxonomy. Each category 740 contains 0...n service 
5 descriptions 750 identifying registered services in that 

category. The service descriptions 750 have associated model 
descriptions 760. The model descriptions 760 provide the 
necessary information for contacting a service provider 770. 
p Thus, when searching registered services on a service broker 

10 ^ 710, the service broker traverses each taxonomy corresponding to 
y| the taxonomy root nodes 73 0 in the taxonomy registry 72 0 and 
fT identifies a category 740 meeting the criteria of the service 
request. Alternatively, this crawling of the taxonomy may be 
based on an identified taxonomy/ category pair in the service 
15 ^ request received. The service broker 710 then identifies one or 
Q more service providers that provide the requested service based 
J: on the registered service descriptions 750 within the identified 
H* category 740. Alternatively, if non-uniform accepted service 
descriptions are used, the service broker 710 may return all 
20 service descriptions registered under a compatible category. The 
associated model description 7 60 may then be used by the service 
consumer to contact the service provider 770. 

It is possible that there may be a plurality of registered 
services that meet the requirements of the service request. In 
25 such an instance, one of the compatible services may be chosen in 
either a specified or arbitrary way. For example, the service 
consumer may be presented with each of the possible candidates 
and allowed to select the service provider that it wishes to use. 
The service providers may be ranked based on prior use of the 
30 service providers and thus, a higher ranked service provider may 
be chosen. Service providers may be selected based upon 
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priorities assigned to non- functional descriptive information 
included in either the service description or the model 
definition. Alternatively, a service provider may be selected 
randomly. Any mechanism by which one service provider may be 
chosen from a plurality of compatible service providers may be 
used without departing from the spirit and scope of the present 
invention. 

As mentioned above, the identification of a service provider 
capable of providing the desired service may be performed at 
runtime. At runtime, there is no human judgment available to 
determine if a service matches a required business need. This is 
not a problem with the present invention since the taxonomy 
architecture of the present invention ensures that services in a 
particular classification will at least satisfy the business 
needs associated with the corresponding CSD's minimum 
requirements. Therefore, an automatic identification of a 
compatible service provider is possible based on the 
classification scheme of the present invention. No human 
intervention is required. 

Thus, with the present invention, a service broker acts as a 
mediary between service consumers and service providers. Based 
on the categorization architecture of the present invention, a 
service registered with the service broker may be automatically 
identified based on the criteria in a service request, and 
corresponding contact information may be provided to the service 
consumer so that the service consumer may contact the service 
provider to obtain the desired service. 

Figure 8 is a flowchart outlining an exemplary operation of 
the present invention when registering a new service with a 
broker. As shown in Figure 8, the operation starts with the a 
registration request being received (step 810) . The registration 
request includes a service description and model description. A 
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determination is made as to whether the service should be added 
to the registered services under the requested classifications 
(step 820) . This determination may include determining if the 
service description of the service to be registered satisfies the 
minimum requirements of the requested classifications in the 
taxonomies supported by the service broker, as identified by 
corresponding canonical service descriptions. If the 
determination is that the service fits the canonical service 
description for the requested classification, the service 
description and model description are added to the list of 
services associated with the selected classification categories 
(step 830) . 

If the service description is not to be added to any of the 
requested classification categories, the service provider may be 
provided with the option to request a new category to be created 
(step 840) . If the service provider does not request a new 
category, the operation ends. If the service provider does 
request a new category, a determination is made as to whether or 
not a new category should be added (step 850) . If so, a new 
category is generated and added to the supported taxonomy (step 
860) . If a new category is not to be added, the operation ends. 

Figure 9 is a flowchart outlining an exemplary operation of 
the present invention when processing a service request from a 
service consumer. As shown in Figure 9, the operation starts 
with receiving a service request from a service consumer (step 
910) . The request includes a service description of the 
requested service. The service description in the service 
request is parsed (step 920) and the taxonomies supported by the 
service broker are searched to determine if any registered 
services meet the service description in the service request 
(step 930). If not, a u no services available" message is 
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returned to the service consumer (step 940) . If one or more 
services are identified, a determination is then made as to 
whether more than one service is identified (step 950) . If so, 
one of the services is selected based on one or more selection 
5 schemes (step 960) . Thereafter, or if only one service is 

identified, the model definition for the identified service is 
provided to the service consumer so that the service consumer may- 
contact the service provider (step 970) . The operation then 
O ends . 

10 <T| Thus, the present invention provides a unified architecture 

for classifying services into taxonomies, and categories within 
il these taxonomies, supported by service brokers in a network. The 
J" unified architecture makes use of canonical service descriptions 
s for purposes of classification and to assure that services meet a 
15 ^ minimum requirement for respectivel categories within the 

□ taxonomies. In addition, the canonical service descriptions may 
2? provide executable tests which may be used to verify a service as 
y ;; meeting minimum requirements for a classification as well as 
provide a mechanism by which compatible classifications may be 
20 identified to a service provider. 

Based on this architecture, service consumers may send 
service requests to service brokers in order to identify those 
service providers that are capable of providing a desired 
service. The service brokers may then provide contact 
25 information to the service consumer such that the consumer may 
contact the service provider to obtain the desired service. 

As a further embodiment of the present invention, the 
canonical service description tests describe above may be used as 
a mechanism for identifying categories in which a service may be 
30 registered. For example, consider the scenario of a service 
provider sending a registration request to a service broker 
identifying a particular category in which a particular service 
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is to be registered. If the service fails the CSD tests required 
for registration in the selected category, the service broker may 
look to other similar categories to determine if the service may 
meet the CSD tests of these other similar categories. 

For example, the service broker may look to sibling, parent 
and/or child categories, within a certain range of the selected 
category in the taxonomy. The CSD tests associated with these 
categories may be applied to the service that is to be registered 
and a determination as to whether the service satisfies the 
minimum requirements of these categories may be made. If the 
service does meet the minimum requirements of one or more of 
these categories, these categories may be identified to the 
service provider so that the service provider may be given the 
option to select one of these categories for registration of the 
service . 

It is important to note that while the present invention has 
been described in the context of a fully functioning data 
processing system, those of ordinary skill in the art will 
appreciate that the processes of the present invention are 
capable of being distributed in the form of a computer readable 
medium of instructions and a variety of forms and that the 
present invention applies equally regardless of the particular 
type of signal bearing media actually used to carry out the 
distribution. Examples of computer readable media include 
recordable- type media such a floppy disc, a hard disk drive, a 
RAM, CD-ROMs, and transmission- type media such as digital and 
analog communications links. 

The description of the present invention has been presented 
for purposes of illustration and description, and is not intended 
to be exhaustive or limited to the invention in the form 
disclosed. Many modifications and variations will be apparent to 
those of ordinary skill in the art. The embodiment was chosen 
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and described in order to best explain the principles of the 
invention, the practical application, and to enable others of 
ordinary skill in the art to understand the invention for various 
embodiments with various modifications as are suited to the 
particular use contemplated. 



